Lernfähigen Assistenten erstellen
Was du nach diesem Kapitel kannst: Du verstehst, was ein "Gedächtnis" in einem 42°OS-Workflow bedeutet — und was es nicht bedeutet. Du kannst Workflows aufbauen, die wiederkehrende Entscheidungen speichern und beim nächsten Durchlauf darauf zurückgreifen. Du kennst verschiedene Speicherstrategien und weißt, wann welche sinnvoll ist.
1. Was "Gedächtnis" bedeutet — und was nicht
Ein lernfähiger Assistent klingt nach künstlicher Intelligenz, die sich mit der Zeit verbessert. Das ist nicht gemeint — und diese Unterscheidung ist wichtig.
Das verwendete KI-Modell in 42°OS ist statisch. Es wird nicht trainiert, verändert sich nicht und akkumuliert kein Wissen über die Zeit. Das gilt für jeden Workflow, der einen Generative AI Agent einsetzt.
"Gedächtnis" in diesem Kontext bedeutet etwas viel Schlichteres: Eine Entscheidung, die einmal getroffen wurde, wird in einer Datenbank oder Datei gesichert. Beim nächsten Durchlauf schaut der Workflow dort zuerst nach — und wenn die Entscheidung bereits vorliegt, wird sie direkt übernommen, ohne den aufwendigen Verarbeitungsschritt erneut zu durchlaufen.
Auch Workflows ganz ohne KI können auf diese Weise ein Gedächtnis erhalten.
2. Wann ist ein Gedächtnis sinnvoll?
Immer dann, wenn ein Workflow wiederholt dieselbe Frage beantworten muss — und die Antwort sich nicht ändert. Zwei typische Szenarien:
Rechnungsfreigabe mit Wiedererkennungswert
Ein Workflow zur Rechnungsverarbeitung enthält einen Human-in-the-Loop-Schritt: Ein Mitarbeiter muss eingehende Rechnungen freigeben. Das funktioniert gut — bis monatlich dieselben Abobeträge desselben Lieferanten zur Freigabe landen. Jedes Mal dieselbe Rechnung manuell zu bestätigen ist Aufwand ohne Mehrwert.
Mit einem Gedächtnis: Beim ersten Durchlauf gibt der Mitarbeiter die Rechnung frei und entscheidet, ob dieses Muster gespeichert werden soll. Beim nächsten Durchlauf erkennt der Workflow Lieferant und Betrag — und leitet die Rechnung direkt durch, ohne erneute Freigabe.
Kunden-Mapping bei der Auftragsverarbeitung
In vielen Unternehmen stimmen die Kundenstammdaten im ERP nicht mit den Angaben überein, die ein Kunde in seiner Bestellung macht — andere Schreibweise, abweichende Firmierung, fehlendes Kürzel. Der Workflow findet den Kunden im ERP nicht und muss eine Rückfrage stellen.
Mit einem Gedächtnis: Beim ersten Auftreten eines unbekannten Kunden geht der Workflow in einen Human-in-the-Loop. Der Mitarbeiter gibt das korrekte Mapping an — "Muster GmbH & Co. KG in der Bestellung = Muster GmbH (Kd.-Nr. 10042) im ERP" — und entscheidet, ob dieses Mapping gespeichert werden soll. Beim nächsten Durchlauf mit denselben Bestelldaten findet der Workflow das Mapping im Gedächtnis und überspringt die Rückfrage.
3. Der Ablauf: Erst nachschlagen, dann entscheiden
Das Grundmuster ist immer dasselbe — unabhängig vom konkreten Anwendungsfall:
[Eingehende Daten]
↓
[Gedächtnis abfragen] → Internal Storage Agent (SELECT)
↓ oder: Excel-Datei lesen vom SMB Share
[Switch Agent]
├── Eintrag gefunden → Entscheidung direkt übernehmen → weiterverarbeiten
└── Kein Eintrag → tatsächliche Verarbeitung (ERP-Abfrage, Human-in-the-Loop, etc.)
↓
[Frage: Soll diese Entscheidung gespeichert werden?]
├── Ja → Gedächtnis schreiben → weiterverarbeiten
└── Nein → nur weiterverarbeiten
Der entscheidende Punkt: Das Gedächtnis wird vor der eigentlichen Verarbeitung abgefragt. Nur wenn kein passender Eintrag vorliegt, läuft der aufwendige Schritt — ERP-Abfrage, KI-Analyse oder manuelle Prüfung. Das Gedächtnis ist damit kein Anhang an den Workflow, sondern eine vorgelagerte Weiche.
4. Speicherstrategien im Vergleich
Internal Storage (SQLite)
Der einfachste Weg. Der Internal Storage Agent schreibt und liest direkt aus der plattformeigenen Datenbank — ohne externe Abhängigkeiten, ohne zusätzliche Konfiguration.
-- Nachschlagen: Gibt es ein bekanntes Mapping für diesen Kunden?
SELECT erp_kundennummer
FROM kunden_mapping
WHERE besteller_name = '{{ besteller_name }}'
LIMIT 1;
-- Speichern: Neues Mapping anlegen
INSERT INTO kunden_mapping (besteller_name, erp_kundennummer, gespeichert_am)
VALUES ('{{ besteller_name }}', '{{ erp_kundennummer }}', '{{ "now" | date: "%Y-%m-%d" }}');
Geeignet für: Schnelle Umsetzung, interne Workflows, wenn die Pflege durch technisch versierte Mitarbeitende erfolgt.
Einschränkung: Direkte Einträge in der Datenbank sind für nicht-technische Mitarbeitende weniger zugänglich.
Excel-Datei auf SMB Share
Eine Excel-Tabelle auf einem freigegebenen Netzlaufwerk dient als Gedächtnis. Der Workflow liest beim Start die Datei, prüft ob ein passender Eintrag vorhanden ist, und schreibt bei Bedarf neue Einträge.
Geeignet für: Anwendungsfälle, in denen Mitarbeitende das Gedächtnis direkt und ohne technisches Wissen bearbeiten sollen — ein vertrautes Interface, keine Datenbankzugriffe.
Einschränkung: Weniger robust als SQL. Gleichzeitige Schreibzugriffe können zu Konflikten führen. Einträge können versehentlich oder absichtlich verändert werden — je nach Anforderung ein Vor- oder Nachteil.
ERP-System oder andere Stammdatensysteme
In manchen Fällen ist das "Gedächtnis" bereits im ERP vorhanden oder gehört dort hin — zum Beispiel ein Kunden-Mapping als Stammdateneintrag. In diesem Fall liest und schreibt der Workflow direkt gegen das ERP.
Geeignet für: Anwendungsfälle, in denen die Entscheidung ohnehin im ERP gepflegt werden muss — das Gedächtnis ist dann keine Parallellösung, sondern Teil des bestehenden Systems.
5. Ablaufdauern für Gedächtnis-Einträge
Nicht jede gespeicherte Entscheidung soll ewig gelten. Eine Rechnungsfreigabe für ein Abo könnte ablaufen, wenn sich der Betrag ändert. Ein Kunden-Mapping könnte nach einem Jahr zur Überprüfung fällig werden.
Solche Ablaufdauern lassen sich über einen separaten Wartungs-Workflow umsetzen, der in regelmäßigen Abständen läuft und Einträge anhand eines gespeicherten Datums prüft:
-- Alle Einträge finden, die älter als 365 Tage sind
SELECT * FROM kunden_mapping
WHERE gespeichert_am < date('now', '-365 days');
Einträge, die das Ablaufdatum überschritten haben, können automatisch gelöscht, markiert oder zur manuellen Überprüfung weitergeleitet werden.
6. Der Human-in-the-Loop als Gedächtnis-Eingabe
In vielen Fällen ist der Moment, an dem eine neue Entscheidung ins Gedächtnis kommt, ein Human-in-the-Loop-Schritt. Der Mitarbeiter trifft nicht nur die Entscheidung — er entscheidet auch, ob diese Entscheidung gespeichert werden soll.
Eine einfache Formulierung im Human-in-the-Loop reicht dafür aus:
"Kunde 'Muster GmbH & Co. KG' wurde keiner ERP-Kundennummer zugeordnet. Bitte gib die zugehörige Kundennummer an. Soll dieses Mapping für zukünftige Anfragen gespeichert werden? [Ja / Nein]"
Nur wenn der Mitarbeiter "Ja" wählt, schreibt der nachgelagerte Schritt den Eintrag ins Gedächtnis. So bleibt die Kontrolle darüber, was gespeichert wird, beim Menschen — der Workflow automatisiert nur das Nachschlagen und Verwenden.
7. Zusammenfassung
| Aspekt | Empfehlung |
|---|---|
| Gedächtnis = KI-Training? | Nein — statische Datenbank, kein Modell-Update |
| Grundmuster | Gedächtnis abfragen → Switch → bei Treffer direkt weiter, sonst verarbeiten & ggf. speichern |
| Speicher für technische Nutzer | Internal Storage (SQLite) |
| Speicher für nicht-technische Nutzer | Excel auf SMB Share |
| Speicher als Teil von Stammdaten | ERP-System |
| Ablaufdauern | Separater Wartungs-Workflow mit Datumsprüfung per SQL |
| Wer entscheidet, was gespeichert wird? | Mitarbeitender im Human-in-the-Loop |
📹 Video zu diesem Kapitel: [Platzhalter — Screencast: Kunden-Mapping-Workflow mit Gedächtnis — vom ersten Human-in-the-Loop bis zum automatischen Durchlauf beim zweiten Mal] 📸 Screenshots: [Platzhalter — Internal Storage Agent SELECT vor der Verarbeitung, Switch Agent auf Gedächtnis-Treffer, Human-in-the-Loop mit Speicher-Option]
Vorheriges Kapitel: [[Zustandsnormalisierung durch SQL-Persistenz]]